Maybe IntFlag instead of IntEnum? (just something to perhaps consider...)

Completely impenetrable name.

Renamed it to split_n_across_workgroups, better?

Again, comments about vec state management apply here, and mutatis mutandis, the rest of the PR.

This cached data is generated by a computer. Therefore there should be no need to parse and evaluate it, because the on-disk representation can just be the in-memory representation.

This cached data is generated by a computer

I preferred a human-readable format to keep the representation valid across pyop2-versions which might not be the case with pickling. (Happy to serialize in a different format if there's a better alternative)

no need to parse and evaluate it,

I don't think we can avoid the evaluates because the grid sizes are typically symbolic expressions of the form: (end - start) // 32 + 1. Therefore the grid sizes are evaluated at runtime during a GlobalKernel.__call__ invocation.

Pickle version incompatibilities are fine (they would appear when you upgrade python and we don't guarantee very much about the portability of on disk cached data between firedrake-update calls, let alone python version upgrades).

What you're attempting to do is cache a function that computes these things. So in the code_to_compile case, just write that function, and pickle it.

Although is this a consequence of the on-disk kernel/compiled code not remembering the loopy representation?

Pickle version incompatibilities are fin

Cool, will change. (Thanks!)

Although is this a consequence of the on-disk kernel/compiled code not remembering the loopy representation?

Yes, the compiled code stores only the plain CUDA/OpenCL device kernel. Loopy's cache on disk mechanism works by storing both the device kernel and the host code that would call end up calling this device kernel. But adapting PyOP2 to call loopy kernels would be a bit disruptive and I think loopy's cache dir being $XDG_CACHE_DIR has run into some problems in the past.

just write that function,

Planning to simply generate a python function corresponding to the expression: inducer/pymbolic#107

For my education, how come you chose to not go with the generated invokers?

For PyOpenCL we could borrow the invoker, but for PyCUDA/C-target we don't have an invoker in loopy (yet).

• Also, for the pyopencl invoker, a minor concern is that the disk-caching semantics don't play well with PyOP2's disk-caching semantics.
• I feel adding an invoker for the PyCUDA target shouldn't be too difficult. Taking a look at it.

There is invoker generation for the C target. I'd expect that putting together CUDA invokers wouldn't be a massive effort based on a copy-paste job of the CL ones. Do you think that might be the right approach?

I am working on integrating the PyCUDA/PyOpenCL invokers. For the C-target, reorganizing pyop2/compilation.py is a bigger undertaking and also out of the scope for this PR.

This is data to be consumed by a computer, so don't make it human-readable and require parsing.

Do you recommend pickling?

This is tremendously fragile. Please think of a better way of saving this data in a way that doesn't rely on dubiously-stable properties of numpy.savez/load.

Agreed. While np.savez-ing the arrays also stored a string-array that tells us the keys that were used for storing these arrays. See https://github.com/OP2/PyOP2/compare/9b7eb97878f2b6609d64affe896c5d4d901a2934..0e58f08d3ea1487e01c45df2270fa9e5790a845d.